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DETAILED ACTION 

1 . Claims 1 -20 are pending. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that 
form the basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or in public 
use or on sale in this country, more than one year prior to the date of application for patent in the United 
States. 

3. Claims 1-2. 4-7. 9-14, and 16-19 are rejected under 35 U.S.C. 102(b) as being 
anticipated by Kocher US Patent No. 5,903,651. Kocher discloses a method for 
demonstrating and confirming the status of digital certificates and other data. 

4. With regards to claim 1 . Kocher teaches the arranging of a plurality of messages 
into an ordered sequence of messages (Kocher, column 6 lines 43-47 "data 

items... sorted in ascending order", column 1 1 lines 33-50), constructing a hash tree 
from the sequence of messages (Kocher, column 7 lines 19-26, hash tree), computing a 
value of a root node of a hash tree (Kocher, column 7 lines 51-54. root node), preparing 
a private key for a digital signature operation (Kocher, column 1 lines 46-50). and 
performing a cryptographic signature operation with the private key upon the value of 
the root node (Kocher, column 8 lines 5-13). 
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5. With regards to claims 2 and 13, Kocher teaches the tree constructed with a 
position dependent hash function (Kocher, column 7 lines 40-43, hash depends oh level 
in the tree). 

6. With regards to claim 4, Kocher teaches a value of the leaves of the hash tree 
being taken as the results of a hash function applied to the values of the sequence of 
messages (Kocher, column 7 lines 33-44, cryptographic hash function). 

7. With regards to claims 5. 9, 1 1 and 18, Kocher teaches the performing of the 
cryptographic signature operation with padding added to the value of the root node 
(Kocher, column 8 lines 5-13, padding viewed as date/time stamp, number of nodes, 
see Figure 9 item 905). 

8. With regards to claim 6, Kocher teaches all that is described above, and further 
teaches the extracting of the public key digital signature from a combination of the hash 
tree and from the results of the cryptographic signature operation (Kocher, column 9 
lines 26-42). 

9. With regards to claims 7 and 19, Kocher teaches the incorporating of a hash tree 
size into the public key digital signature where the hash tree size is the number of the 
plurality of messages (Kocher, column 8 lines 5-13 "number of nodes", see Figure 9 
item 904). 

1 0. With regards to claims 1 0, 1 2 and 1 7, Kocher teaches the parsing of the public 
key digital signature and the retrieving of its signature data (Kocher, column 8 lines 34- 
38, column 9 lines 26-36), the ascertaining that the signature data comprises a stated 
signature value and a stated sibling value and position sequence (Kocher, column 8 
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lines 29-32), computing a hash tree branch comprising a leaf node and a root node 
(Kocher, column 10 lines 1-20, column 9 lines 39-44, Figure 14), the hash tree branch 
being computed with the value of the individual message and with the stated sibling 
value and position sequence (Kocher, column 9 lines 39-44), and performing a 
verification operation on the stated signature value with the value of the root node and 
with the public key (Kocher, column 9 liens 26-52). 

1 1 . With regards to claim 14, Kocher teaches the ascertaining that the signature data 
comprises a hash tree size (Kocher, column 9 lines 60-61 ), the detemriining of a tree 
representative of the tree family and whether or not the shape of the hash tree branch is 
a valid branch of the tree (Kocher, column 9 line 53 - column 10 line 20). 

12. With regards to claim 1 6, Kocher teaches the value of the leaf of the hash tree 
branch taken as the result of a hash function applied to the value of the individual 
message (Kocher, column 7 lines 33-43). 



Claim Rejections - 35 USC § 103 



13. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 
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14. Claims 3, 8. 15. and 20 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Kocher US Patent No. 5,903.651 in view of Ostrovosky et al US 
Patent No. 5.123.045. 

15. With regards to claims 3, 8, 15. and 20, Kocher fails to teach the hash tree 
constructed using a hash function with a salt value. Ostrovosky teaches a hash tree 
constructed using a hash function with a salt value (Ostrovosky, column 6 lines 46-67). 
At the time the invention was made, it would have been obvious to a person of ordinary 
skill in the art to utilize Ostrovosky's method of hashing with Kocher's system because it 
offers the advantage of providing a random function that helps prevent attackers from 
corrupting memory locations (Ostrovosky, column 3 lines 28-57). 



Conclusion 

16. The prior art made of record and not relied upon is considered pertinent to 
applicant's disclosure, 

17. Simon et al US Patent No. 6,065,008 discloses a system for secure font subset 
distribution. 

18. Kaliski Jr US Patent No. 6,189,098 discloses a client/server protocol for proving 
authenticity. 

19. Ansper et al US PG Pub 2001/0032314 discloses a method for validating a digital 
signature. 

20. Karjoth et al US PG Pub 2001/0034839 discloses a method for secure 
transmission of data and applications. 
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21 . Any inquiry concerning tiiis communication or earlier communications from the 
examiner should be directed to Andrew L Nalven whose telephone number is 703 305 
8407. The examiner can normally be reached on Monday - Thursday 8-6, Alternate 
Fridays, 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Gregory Morse can be reached on 703 308 4789. The fax phone number 
for the organization where this application or proceeding is assigned is 703-872-9306. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more infomnation about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

Andrew Nalven 
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Digital Signatures for Flows and Multicasts 

Chung Kei Wong, Student Member. IEEE, and Simon S. Lam. Fellow, IEEE 



Abstract — ^We present chaining techniques for signing/verifying 
multiple packets using a single signing/verification operation. 
Wc then present flow signing and verification procedures based 
upon a tree-chaining technique. Since a single signing/verification 
operation is amortized over many packets, these procedures 
improve signing and verification rates by one to two orders 
of magnitude, compared to the approach of signing/verifying 
packets individually. Our procedures do not depend upon reliable 
delivery of packets. They also provide delay-bounded signing, 
and arc thus suitable for delay-sensitive flows and multicast 
applications. To further improve our procedures, we propose 
several extensions (o the Feige-Fiat-Shamir digital signature 
scheme to substantially speed up both the signing and verification 
operations, as well as to allow ^'adjustable and incremental" 
verification. The extended scheme, called cFKS, is compared to 
four other digital signature schemes (RSA, DSA, FlGamal, and 
Rabin). Wc compare their signing and verification times, as well 
as key and signature sizes. We observe that: 1) eFFS is the 
fastest in signing (by a large margin over any of the other 
four schemes) and as fast as RSA in verificiition (tie for a close 
second behind Rabin); 2) eFFS allows a tradeoff between memory 
and signing/verification time; and 3) eFFS allows adjustable and 
incremental verification by receivers. 

I. Introduction 

DATA confidentiality, authenticity, integrity, and nonre- 
pudiation are basic concerns of securing data delivery 
over an insecure nciwork, such as the Inlernet. Confidentiality 
means that only authorized receivers will get the data; au- 
thenticity, an authorized receiver can verify the identity of 
the data's source; integrity, an authorized receiver can verify 
that received data have not been modified; nonrepudiation, an 
authorized receiver can prove to a third party the identity of 
the data's source.' 

Most investigations on securing data delivery over packet 
networks have focused on unicast delivery of data sent as 
independent packets. Exceptions include recent papers on 
scalable secure multicasting [1], [13], [20] and a flow-based 
approach to datagram security [14]. All of these papers are 
mainly concerned with data confidentiality. 

In this paper, our concerns are data aulhenlicity, integrity, 
and nonrepudiation for delay-sensitive packet flows, particu- 
larly flows to be delivered to large groups of receivers. For an 

Manuscript received January 27, 1999; revised June 14, 1999; approved 
hy il:l{i:/ACM Transactions on NnWRKiNCi liditor J. Crowcroft This 
work was supported m part by Texas Advanced Research Program under 
Grant OO3f>58-063 and by the NSA INK)SI-:C University Research Program 
under (irant MI)A904-98 C- A9()l , An earlier version ot" this paper appears 
in hxK eedinyfs llihh: ICNl' VH. 

(he authors arc with the Depannicnl of Computer Sciences, the 
University t>f Texas at Austin. Austin. TX 7K?i2-n«H USA (e-mail: 
ckwong(<{!computer.org; laiiKtrcs.utexas.edu ). 

Publisher Item Ideniincr S l063-6692(99)07274-X. 

' In t!ie biilance oi this paper, we use ''receiver" to mean "authorized 
receiver" unless otherwise stated. 



individual message (packet), these concerns can be addressed 
by one of many available digital signature schemes [6], [15], 
[17], [19]. However, these schemes are not efficient enough 
for signing/verifying packets individually for delay-sensitive 
flows, such as packet video. 

In the Internet, multicast has been used successfully to 
provide an efficient, best-effort delivery service to large groups 
[2]. Consider a packet flow multicasted to a group of receivers. 
A consequence of best-effort delivery is that many receivers 
will not receive all of the packets in the multicasted flow. 
Furthermore, many multicast applications allow receivers to 
have widely varying capabilities (e.g., lo receive layered video 
and audio transmissions) or needs (e.g., to receive different 
stock quotes, news, etc.). Consequently, receivers get different 
subsequences of packets from the same multicasted flow. 

A. Existing Techniques for Signing Flows 

Conceptually, a digital signature scheme is defined by 
functions for key generation, signing, and verification. The 
signer (sender) uses the key generation function lo create a 
pair of keys, a signing key A;^, and a verification key k^,. The 
signer keeps the signing key private, and makes the verification 
key publicly known to all verifiers (receivers)."^ 

To sign a message m using signing key k^, the signer calls 
the signing function which returns the signature of message 
m. The signer then sends the signed message, consisting of 
message m and its signature, to verifiers. Having received the 
signed message, a verifier calls the verification function with 
key k^j. If the verification function returns true, then the verifier 
concludes that the signer did sign the message and the message 
has not been altered. Moreover, the signer cannot deny having 
signed the message (nonrepudiation). 

In practice, a message digest function, .such as MD5 [18], is 
first applied to the message to generate a fixed-size message 
digest which is independent of message size. Signing a nies- 
sage means signing the digest of the message. (MD5 message 
digests are 128 bits long.) 

A flow is a sequence of packets characterized by some 
auribute [16], [21], Packets in a flow may be obtained from 
segmenting the bit stream of digitized video, digitized audio, 
or a large file. They may also be related data items, such as 
slock quotes, news, etc., generated by the same source. 

It is easy and efficient lo sign an all-or-nothing flow, that 
is, a flow whose entire content is needed before any part of it 
can be used, e.g., a long file. In this case, the signer simply 
generates a message digest of the entire flow (file) and signs 
the message digest. 

' l he signing and verification key.s arc also referred to hs private and puhlic 
iteys. respectively. 
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Most applications, however, create flows that are not all-or- 
nothing. Thai is, a receiver needs lo verify individual packets 
(or, more generally, application data units) and use them before 
the entire flow is received. For these flows, a straightforward 
solution is to sign each packet individually and each packet is 
verified individually by receivers. This solution is called the 
sign -each approach. 

The sign-each approach is computationally expensive. The 
signing rate and verification rate are at most ^/{Td{l) -{-T^i^n) 
and l/{Ta{l) -f Tyorify) packels/s, respectively, where Td(l) is 
the time to compute the message digest of an /-byte packet, 
Tiigi, is signing time, and Ty^rify is verification time for the 
message digest of a packet. The signing and verification rates,* 
in packets/s, of two widely used digital signature schemes, 
RSA [19]'* and DSA [15], with 512-bit modulus and using 
100% processor time of a Pentium 11 300-MHz machine are 
shown below: 



packet size Signing rate Verification rate 

(bytes) RSA DSA RSA DSA 

512 78.8 176 2180 128 

1024 78.7 175 1960 127 

2048 78.0 172 1620 126 



receiver must have received every packet from the beginning 
of the sequence. 

For a real-time generated flow, a similar technique is 
suggested in [7] with the same get-all-before requirement. 
For a sequence of rn packets, only one expensive sign- 
ing/verification operation is needed, plus one inexpensive 
one-time signature signing/verification for each packet in the 
sequence. However, since one-lime signatures and keys are 
very large, this technique has a large communication overhead 
(around 1000 bytes/packet) [9], [10]. 

The get-all-before requirement of both techniques in [7] is 
loo strong for practical Internet applications. Reliable packet 
delivery is not used by many applications for flows and 
multicasts. For example, reliable delivery is generally not used 
for video and audio flows due to the extra delays associated 
with retransmissions; either losses are tolerated or forward 
error correction techniques are used instead. 

For large-scale multicast applications, reliable delivery of 
multicast packets is a difficult problem [5]. Moreover, even 
if reliable multicasting is available, receivers with diflerenl 
needs/capabilities may choose to get different subsequences 
of packets in a multicasted flow, in short, the get-ail-before 
requirement is not satisfied. 



If a slower machine is used, or only a fraction of proces- 
sor time is available for signing/verification (e.g., a receiver 
machine has only 20% processor time for verification because 
the other 80% is needed for receiving and processing packets), 
then the rates should be decreased proportionally. 

The signing rate is not important for a nonreal-iinw gener- 
ated flow, i.e., a flow whose entire content is known in advance 
(such as stored video). This is because packets in the flow can 
be signed in advance. For a real-time generated flow, however, 
the signing rale must be higher than the packet-generation rate 
of the flow. Furthermore, for delay-sensitive flows, real-time 
generated or not, the verification rate is important. From the 
above table, we see that the signing and verification rates of the 
sign-each approach, using cither RSA or DSA, are probably 
inadequate for many applications. 

Two techniques were previously proposed for signing digital 
streams [7] which, at first glance, may be used for signing 
packet flows. To describe the technique in [7] for signing 
a nonreal-lime generated flow, consider a sequence of m 
packets. The sender fwsi computes message digest of 
packet m (the last packet) and concatenates packet m - 1 
and to form augmented packet m - 1. Then, for i = 
1, ■ • ,)7i - 2, the sender computes message digest i^„,-i of 
augmented packet m-i, and concatenates packet ni-i-l and 
D„i^i to form augmented packet m - i - I, Message digest 
Oi of augmented packet I is computed and signed. In this 
manner, only one expensive signing/verification operation is 
needed for the sequence of m packets. However, a necessary 
condition for using the above technique is the following get- 
all-hefore requirement: To verify packet i in the sequence, a 

'The signing and vcrilication rates are rates for signing and verifying 
l2H-bii message digests of packets. 

**ln this paper, we use r = 3 in RSA to obtain its fastest verilication time 
without aniviing its signing time. 



B. Characteristics and Requirements 

We have observed various characteristics in the delivery of 
flows and multicasts by an unreliable packet network, such as 
the Internet. They are summarized below. 

• Each packet in a flow may be used as soon as it is 
received. 

• A receiver may get only a subsequence of the packets in a 
flow. Different receivers may gel different subsequences. 

• Delay sensitive flows require fast processing at receivers. 
Real-time generated flows require fast processing at 
senders as well. 

• For a multicasted flow, many receivers are limited in 
resources (processing capacity, memory, communication 
bandwidth, etc) compared to ihe sender, which is typi- 
cally a dedicated server machine. In some environments, 
both senders and receivers may be limited in resources, 
e.g., mobile computers using wireless communications. 

• Receivers may have w\de\y different capabili- 
ties/resources. For example, receivers may be personal 
digital assistants, notebook computers, or desktop 
machines. Moreover, the resources available lo a receiver 
for verifying signatures may vary over lime. 

Given the above characteristics, we design procedures for 
signing and verifying flows in Section II, as well as a dig- 
ital signature scheme in Section III lo meet the following 
requirements. 

• The signing procedure is efficient and, for real-time 
generated flows, delay bounded. 

• The verification procedure is cflicient (since many re- 
ceivers have limited resources). 

• Packets in a flow arc individually verifiable. 

• Packet signatures are small (i.e., small communication 
overhead). 
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• Adjustable and incremental verification: The verification 
operation is adjustable to the amount of resources a 
receiver has. It allows a receiver/verifier to verify a 
message at a lower security level using less resources, and 
later increase the security level by using more resources 
(e.g., if the message is important), 

C Contributions of this Paper 

In Section II, we first describe and compare two chaining 
techniques (star and tree) for signing/verifying multiple pack- 
ets using a single signing/verification operation (without the 
gct-all-bcfore requirement in [7]). We then present flow sign- 
ing and verification procedures based upon the tree-chaining 
technique. Since a single signing/verification operation is 
amortized over many packets, these procedures improve sign- 
ing and verification rates by one to two orders of magnitude 
compared to the sign-each approach. The signing procedure 
also provides delay-bounded signing. Thus the procedures can 
be used for delay-sensitive flows. 

Since signed packets in our procedures are individually 
verifiable, the procedures can be used to reduce the workload 
oUwy machine that sends out a large number of signed packets 
to one or more destinations. There is no requirement that these 
packets belong to flows. However, for packets that belong to a 
flow, the workload of the flow's receiver(s) is also reduced. 

In Section Iff, we turn our attention to improving the signing 
and verification operations in the procedures. Specifically, we 
present several extensions to the Feige-Fiat-Shamir digital 
signature scheme to speed up both signing and verification 
as well as to allow adjustable and incremental verification. In 
Section IV, the extended Feige-Fiai-Shamir (eFFS) scheme 
is compared to four well-known signature schemes [6], [I5J, 
117], [19J, We compare their signing and verification times, 
as well as key and signature sizes. We observe that: 1) eFFS 
is the fastest in signing (by a large margin over any of the 
other four schemes) and as fast as RSA in verification (tie 
for a close second behind Rabin); 2) eFFS allows a tradeoIT 
between memory and signing/verification time; and 3) cFFS 
allows adjustable and incremental verification by receivers. 

n. How TO StoN A Flow 
To digitally sign/verify delay-sensitive flows, the sign-each 
approach is computationally loo expensive for many applica- 
tions, particulariy those applications that generate packet flows 
in real lime. 

As an alternative to the sign-each approach, we present two 
chaining techniques (star and tree) for providing authenticity 
to a group of packets, called a block, using a single signing 
operation. The basic idea is to compute a block digest which 
IS signed. In order to make packets individually verifiable, 
each packet needs to carry its own authentication information 
consisting of the signed block digest {block signature) together 
with .some chaining information as proof that the packet is in 
the block. 

A. Star Chaining 

Consider m. packets that constitute a block. In star chaining, 
the block digest is simply the message digest of the m packet 




Fig. I. Star-chaining icchntquc. 

digests (listed sequentially). Let denote the message 
digest function being used (e.g., MD5). Consider, for example, 
a block of eight packets with packet digests Di. - .Dq, 
The block digest is D^-s = ■ • , Og), and the block 

signature sign{Di^s) is the block digest signed with some 
digital signature scheme (such as RSA, DSA, or eFFS). 

The relationship between the packet digests and the block 
digest can be represented by a one-level rooted tree, called an 
authentication star. Fig. I illustrates an authentication star for 
eight packets, with packet digests at leaf nodes, and the block 
digest at the root. 

For packets to be individually verifiable, each packet needs 
its own authentication information. Such authentication infor- 
mation, called packet signature, consists of the block signature, 
the packet position in the block, and the digests of all other 
packets in the block. (We use the term chaining overhead to 
refer to all information in a packet signature except the block 
signature.) 

Suppose the third packet in the above example is received, 
its authenticity can be individually v^vifiod as follows. The 
verifier computes the digest D'^ of ihe packet received, and 
then the block digest D\_^ = KDu D2, Di^, D^, - • ■ , Ds), 
where Di,D2,D.x, - • are carried in the packet signature. 
The verifier then calls the verification operation to verify D\_^^ 
i.e., to determine whether D[_^ is equal to block digest Di_a 
in block signature sign(Di-s)- The packet is verified if the 
verification operation returns true, i.e., D\^^ ~ Di-&, 

Suppose the third packet is the first in the block to arrive 
and its authenticity has been verified. Afterwards, the verifier 
knows every node in the authentication star, i.e., all nodes in 
the authentication star are verified and can be cached. With 
caching, when another packet m the block arrives later, say 
the sixth packet, the verifier only needs to compute the digest 
Dq of the packet received and compare it to the verified node 
in the authentication star. If they are equal, the packet is 
verified. 

B. Tree Chaining 

Tree chaining subsumes star chaining as a special case. With 
tree chaining, the block digest is computed as the root node of 
an authentication tree} Consider, For example, a block of eight 
packets with packet digests Di, • Mh- Tht^ packet digests 
arc the leaf nodes of a dcgrcc-two (binary) authentication tree, 
with other nodes of the tree computed as mcs.sage digests of 

^Trcc chaining was tirst presented in (1 1|. Any rooted tree can tie used as 
an autlienlicatitMi lice witli pacticl digests at leaf nodes and the block digest 
at the root. In particular, there is no need to use a balanced tree. 
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Fig. 2. Tree-chaining technique. 

their children, as shown in Fig. 2. For example, the parent of 
the leaves Di and D2 is D12 = h(Di,D2), where /i( ) is 
the message digest function being used. The root is the block 
digest, with the block signature being the signed block digest. 

For a packet to be individually verifiable, each packet needs 
to carry its own authentication information (packet signature). 
In tree chaining, a packet signature consists of the block 
signature, the packet position in the block, and the siblings of 
each node in the packet's path to the root. (Again, we use the 
terni chaining overhead to denote all information in a packet 
signature except the block signature.) 

^ To verify a packet individually, a verifier needs to verify 
its path to the root. Consider, for example, the dashed path 
in Fig. 2 for the third packet. Each node in the path needs to 
be verified. A verifier computes the digest D'^ of the received 
packet, and then each of its ancestors in the tree. Thai is, 
A3^4 = /^(^i,^4), D[_, = and Z^U = 

'^(^i "4 > ^5-8)1 where i>4,£)i_2 and Z>o-8 are carried in 
the packet signature. The verifier then calls the verification 
operation to determine whether D[_f^ is equal to block digest 
in block signature sign{Di-s). The packet is verified if . 

yjhe verification operation returns true, i.e., 0[_f^ — Dis -J 
" Suppose the third packet is the first in the block to arrive. 
After verifying it, the verifier knows the following nodes^ in 
the authentication tree: Z^a, Z)i.-2, ^3-1, ^5-8 and 
the block digest Di-a- These are verified nodes which can be 
cached. By caching verified nodes, the verifier only needs to 
compute each node in the authentication tree at most once. 

For example, after verifying the third packet, to verify 
the sixth packet which arrives later, the verifier computes 
the digest of the [>^ckc\ received i^g, its parent D''^_q ~ 
h{D:,,D'^)^ and its grandparem = /{(D^^g, Dt-s). If 

D^^rt <^qi^al to the cached node the sixth packet is 

verified. 

C. Comparison of Chaining Techniques 

We pertonncd experiments on a Pentium II 300-MII/. ma- 
chine running Linux, and compared star and tree chaining. We 
used MD5 as the message digest function [I8| for generating 

"Some arc carried in ihe packet signature and (he others have been 
computed. 
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Fig. 3. MD5 computation time (milliseconds). 



128-bit message digests. Fig. 3 shows the MD5 computation 
lime versus input size. We observe that the MD5 computation 
time can be regarded as a linear function in input size (for a 
large input, i.e., 1024 bytes or more). 

For each chaining technique, an authentication tree is first 
built for a block of packets,^ i.e., each node is computed 
as the message digest of its children. The time to build aii^ 
Authentication tree (excluding time to compute packet digests 
for leaf nodes) is called the free build time. The block signature 
is then obtained by signing the block digest at the root. After 
that, the packet signature of each packet is built from the 
authentication tree and the block signature. The time to build 
a packet signature is called packet signature build time. The 
chaining time for a block at a signer is the sum of tree build 
lime and packet signature build time for all packets in the 
block. ^ Fig. 4(a) shows the chaining time for a block of packets 
at a signer. 

Consider the total signing time for all packets in a block, 
which is the block's chaining time plus the signing time of 
the block digest. The block digest signing time is 12.7 ms 
using 512-bit RSA and 5.6 ms using 512-bit DSA. For a block 
of 16 packets, from Fig. 4(a), the chaining time is 0.21 ms 
for a degree-two authentication tree. The total signing time is 
0.21 + 12.7 = 12.9 ms using 512-bit RSA. Thus, the average 
signing time for one packet is 12.9/lC = 0.81 ms, which is 
less than 1/15 of the block digest signing lime using 512-bit 
RSA. 

To verify packets in a block, an authentication tree is built 
from packet signatures as packets arrive. The chaining time 
for a block at a verifier is the sum of tree build time and time 
to verify chaining infonnation in the packet signature of every 
packet in the block.*^ Fig, 4(b) shows the chaining time for a 
block of packets at a verifier with caching of verified nodes. 

Consider the total verification time for all packets in a block, 
which is the block's chaining lime plus the verification lime of 
the block signature. The signature verification time is 0.40 ms 
using 512-bil RSA and 7.6 ms using 512-bit DSA. For a block 
of 16 packets, from Fig. 4(b), the chaining lime is 0.24 ms tor 
a degree-two authentication tree. The total verification time is 

^\Vc will use "tree" instead of "iree.'star" since star cliamiiig is a special 
ease of tree cliaining. 

**Note that chaining time does not include tune to compute packet digests 
for leaf nodes and time to sign the block digest, 

**Noie that chaining time does not include time to compute packet digests 
for leaf nodes and time to verify the block signature. 



506 



IEEE/ACM TRANSACTIONS ON NETWORKING. VOL. 7. NO, 4, AUGUST 1999 




1000 



aoi 



6 16 32 
block size 

(a) 



I 
at 
E 



(0 

■5 




0.01 

6 16 32 
block size 

(b) 

Fig. 4. Chaining lime (milliseconds) for a block (a) at a signer and (b) at a 
verifier (with caching of verified nodes). 



0.24+0.40 = 0,04 ms using 5i2-bil RSA. Thus the average 
verification time for one packet is 0.64/lC = 0.04 ms, which 
is 1/10 of the signature verification time using 512-bit RSA. 

From Fig. 4(a), note lhai for any block size smaller than or 
equal lo 64 packets, star chaining takes less lime at a signer 
than tree chaining (degrees two lo eight). However, for a larger 
block size, star chaining lakes more lime at a signer than iree 
chaining, because the chaining litne for a star is O(m^) and 
the chaining time for a tree is 0(m log(m)), where m denotes 
block size. 

As shown in Fig. 4(b), star chaining takes less lime at a 
verifier than tree chaining for all block sizes. 

For each chaining lechnique, a packet signature has two 
pans, the block signature and the chaining overhead. In 
general, if a tree is not balanced and full, the chaining 
overhead sizes of different packets arc different. Fig. 5 shows 
the average chaining overhead size per packet. The size of ihe 
block signature is not included in Fig. 5 since it depends on 
which signature scheme is used (e.g., the block signature is 64 
bytes for 5l2-bu RSA, and 40 bytes for 512-bU DSA). 

From Fig, 5. note that the chaining overhead of star chaining 
is much greater than tree chaining for block sizes larger than 
eight. If a small communication overhead is important, packet 
signature sizes should be reduced. We recommend Ihe u.se of 
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degree-two tree chaining which requires the smallest chaining 
overhead, (From Fig. 4, a degree-two tree has a slightly 
higher chaining time than the alternatives, but the difference 
is insignificant because chaining time is much smaller than 
signing/verification time of the block digest. Sec Figs. 7 and 
8 in Section II-D.) 

D. Flow Signing and Verification Procedures 

A flow is signed by partitioning it into blocks of packets, 

with each block signed using tree chaining. For a nonreal- 
time generated flow, blocks are of the same size m, chosen 
lo be a power of the aulheniication tree degree d. For a real- 
lime generated flow, the packet generation rate is time-varying 
for many applications, such as compressed video and voice- 
activated audio. For these applications, partitioning the flow 
into fixed-size blocks may lead to an unpredictable (perhaps 
unbounded) signing delay. Instead, the flow is partitioned by 
fixed time periods, and packets generated in the same time 
period are grouped into a block (see Fig. 6). 

For both real-time and nonreal-time generated flows, the 
flow verification procedure is the same. For the first received 
packet in a block, i.e., the block signature carried in the packet 
signature is new to a verifier, the verifier computes the packet 
digest, and every ancestor of the packet digest.'" For the 
computed block digest (the root of authentication tree), the 
verifier calls the verification operation to verify that it is equal 
to the block digest in the block signature. If so verified, then 
all computed nodes and their children arc verified and cached. 

For a packet that is not the first received packet in a 
block, the verifier computes the packet digest. If the packet 
digest has been cached and the cached value is equal lo the 

•"An ancestor node is computed as the message digest of its children which 
arc ciiher computed or carried in ihe packci signaiurc. 
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Fig. 8. Flow verification rale (packets/s) for 1024-byte packets, (a) Using 
512-bit RSA. (b) Using 512-bit DSA. 



computed packet digest, then the packet is verified. Otherwise, 
the verifier computes every noncachcd ancestor of the packet 
digest. For the highest noncached node computed, the verifier 
then computes its parent. If the computed parent and its cached 
value are equal, the packet is verified and all computed nodes 
and their children are verified and cached. 

We implemented the flow signing and verification proce- 
dures (see Appendix) and perfomied experiments on a Pentium 
(1 300-MHz machine running Linux. We used MD5 as the 
message digest function, and cxperimenled with both 512- 
bit RSA and 512-bit DSA as the signature scheme for block 
signatures. 

Figs. 7 and 8 show, respectively, the flow signing and 
verification rates for 1024-byte packets." Note thai tree and 
star chaining are one to two orders of magnitude more efficient 
than the sign-each approach. The flow signing and verification 
rales increase with block size. However, ihe rales vary only 
slightly with the chaining technique used and with the tree 
degree in tree chaining. Since degree-two tree chaining has 
the lowest chaining overhead (packet signature size), we 
recommend the use of degree-two tree chaining. 

Figs, y and 10 show, respectively, the flow signing and 
verification rates for packets of size 512, 1024, or 2048 bytes. 
Wc used degrcc-two tree chaining. From the figures, observe 

Verification rates were computed assuming no packet loss. 



that the flow signing and verification rates decrease as the 
packet size increases. It is because more time is needed to 
compute the message digest of a larger packet. The decrease 
is more pronounced when the block size used is large, since 
more time is used to compute packet digests for a large block 
than a small block. Observe also that the flow signing and 
verification rates increase with block size and the increase is 
greater for a smaller packet size. 

E. Bounded Delay Signing 

Consider Fig. 6. Assume that, in period 2\ at most m 
packets are generated and their packet digests computed. The 
time for signing a block of m packets is diain,(m) + 
where chain, (m) is the chaining lime for a block of rn 
packets at a signer, and Tsi^u is the block digest signing lime. 
Therefore, the delay of any packet within the block is at most 
D, = 7' + chain, (m) + 

Table I shows the delay upper bound D, for period T = 50 
ms. Note that the upper bound is fairly insensitive lo block 
size since the block^s chaining time is much smaller than the 
block digest signing lime. 

For a given application with a specified upper bound, 
for signing a real-time generated flow at a known packet rate, 
we can work backward and derive an appropriate value for 
the parameter T needed for the signing procedure of a real- 
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number of packets generated in period T 
2 4 8 16 32 64 128 


tree deg 2 
tree deg 4 
tree deg 8 


62.9 62.9 62.9 63.1 63.3 63.8 64.9 
62.8 62.9 02.9 03.0 63.2 63.5 64.2 
62.8 62.9 62.9 63.0 63.2 63.5 64.2 



time generated flow. Observe, from Fig. 6. that T must be 
larger than Tsi^,, + chaiUs (r/i), and must be larger than 
2C^ii«ii + diaina{r?i)). 

F. Selecfing a Digital Signature Scheme 

For nonreal-time generated flows, signing efficiency is not 
critical. Thus a signature scheme with an efficient verification 
operation, such as RSA, can be used in the flow signing 
and verification procedures. For real-time generated flows, 
however, it is critical that both signing and verification are 
highly eflicient. Furthermore, in choosing a digital signature 
scheme, we must also consider machine capabilities (sender 
and receiver), as well as the fraction of processor time avail- 
able for signing and verification. 

Using 100% processor lime of a Pentiuin II 300-MHz 
machine, the flow signing and verification rates for 1024-byte 



packets, degree-two tree chaining, and block size 16 are shown 
below: 



signing rate verification rate 

512-bil RSA 1090 packels/sec 7030 packets/sec 
512-bit DSA 2140 packels/sec 1660 packels/sec 



Note that using DSA, the flow verification rate is smaller 
than the flow signing rate. This is undesirable because 
receivers/verifiers are generally less powerful than the 
signer/sender, e.g., the receivers may be personal digital 
assistants or low-end notebook cornpulers. Using RSA, 
the flow signing rate may not be high enough for some 
applications. Although we can increase the flow signing and 
verification rates by using a longer period or a larger block 
size, neither option is desirable. A larger block size increases 
the chaining overhead (packet signature size). A longer period 
increases the delay for signing real-time generated flows. 

To obtain a signature scheme better than RSA and DSA 
for signing/verifying flows, wc propose several extensions lo 
the Feige-Fial-Shamir (FFS) signature scheme. The exlended 
scheme, called eFFS, is presented in the next section. The 
cFFS scheme has a very eflicient signing operation (much 
more eflicient than those of RSA and DSA) and a verification 
operation as efficient as that of RSA. A performance compari- 
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son of eFFS with five other signature schemes (including FFS, 
RSA and DSA) is given in Section IV. 

III. TnK eFFS Signature Scheme 

In Section IH-A, we first describe the basic FFS signature 
scheme [3], [4]. The eFFS signature scheme is derived from 
FFS with two kinds of extensions. Three extensions to speed 
up the signing and verification operations of FFS are presented 
in Section III-B. An extension to provide adjustable and 
incremental signature verification is presented in Section III-C. 

A. Basic FFS Scheme 

In the basic FFS signature scheme with parameter {k,t) 
[3], [4], each signer chooses two large primes p and and 
computes modulus n = pq. Then, the signer chooses k integers 
'wi , ' " , ^A; (or k integers «i , • • , a*a;)» and computes , ■ ■ , ^Jfc 
(or Viy" ,,Vk) by sf = v^^modn. The signing key is 
{^i, ■ • • , 5A;,n} and the verification key is {t^i, ♦ • ,Vk,n}, 

To sign message m, the signer does the following steps: 

1) choose t random integers, between 1 and n, 
and compute Xi — r?iiiod?i for i = l,-",t; 2) calculate 
the message digest h{myXi, • • , a^t) where the message digest 
function ) is public knowledge and the message digest is 
at least k x t bits long; let {hij} be the first k x t bits of 
the message digest where i = 1, ■ ■ • , and j/ = 1, • • • , /c; 3) 
compute Vi = ri x (/i" x • • x s^^'' ) mod n for z = 1, ■ • • , t. 
The signature of message m consists of {y,} for i = 1, • ,t 
and {bij ) for i = 1 , • • , t and j = 1, • • • , A:. 

To verify the signature of message m, a verifier computes 
- yf X {vi'* X . • X mod n for i = 
The signature is valid if and only if the first k x t bits of 
h{ni,zi,' - ' ,zt) are equal to the {bij} received. (It can be 
shown that z,- computed by the verifier is equal to Xi at the 
signer.) 

The security level of FFS(A;,<) depends on the following: I) 
the size of modulus n (i.e., the size of the primes p and q) and 

2) the value of product kt. A system with a larger modulus is 
more secure, and a system with a larger kt product is more 
secure, if two systems have the same modulus and same kt 
product (but different k and t values), then their security levels 
are about the same. 

Assuming \vi\ = \n\ and \3i\ = jyij, where |:t'| denotes 
the size of x in bits, the signing/verification key size is 
(A: + 1) X |n| bits, and the signature size is t x |n| + kKt bits. 
The signing/verification key size only depends on k, but the 
signature size is proportional to t. Thus, for a fixed kt product, 
we can reduce the signature size by using a smaller t (and a 
larger k). For t = I, the signature size is minimized, but the 
signing/verification key size is maximized. Table II shows the 
signing/verification key size and signature size of FFS with 
512-bit modulus. 

IS. Extensions to Spcvd up FFS 

1) Small Verijication Key (small v-key): In FI-S, (he sizes 
of signing key components {3,] alfcct the signing time, 
and the sizes of verification key components [vi] alTect the 
verification time. An improvement suggested in [12J is to 
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use the first k prime numbers as verification key components 
{vi). However, since not every prime number p satisfies 
the condition thai there exists an integer 3 such that = 
p"^ modn, we propose to use the first k prime numbers 
that satisfy this condition as verification key components.'^ 
This extension reduces both the verification time and the 
verification key size, 

2) Chinese Remainder Theorem (art): The signing opera- 
tion in FFS involves the computing of Vi = ?i x {s\^ x 
• " X 5^'*') mod w. For n = pq, from the Chinese Remainder 
Theorem, a signer can compute yi from and hi using the 
following formula: Vi = ((a^ ~ hi) x q Xi + 6i)modn 
where q~^ = q~^ mod/;, = x (^J'* x • • • x .9j^'*=)modp 
and bi - u x (s}'* x ■•• x s^^*')modq. Thus, instead of 
computing yi directly with multiplication operations in modn, 
a signer first computes ai and bi with multiplication operations 
in, respectively, uiodp and mod f/. Then pi is computed from 
ai and 6t . Since multiplication operations in inodp and mod (7 
are more eflficient than in mod n, the signing lime is decreased. 

This Chinese Remainder Theorem improvement can only be 
used by a signer because knowledge of the factors of modulus 
n is required. A few hundred bytes of additional memory are 
needed for storing a few large integers (for 512-bit modulus). 

3) Precomputation (precomp): A signer can further speed 
up the signing operation by using more memory. To illustrate 
the basic idea of this improvement, consider the signing 
operation with /: = 4. To sign a message, a signer computes 
Vi - I'i X [s\'^ X • • X s$'"*)modn, for i = 1, • • • , t. Since 
5i, • ,54 do not change from message 10 message, and 
^ii, ■ ■ ,^i4 are either one or zero, the signer can precompule 
and store the product (modn) of every nonempty subset 
of [si, " ,3A. Let S{,^...{f^ denote the precomputed product 
3\^ X • • • X 3,* mod n. Then, to sign a message, the signer 
simply computes yi by Vi x mod n. 

For large k, it is not practical to precompute the product 
(modn) of every nonempty subset of {.^fi, • * • Instead, 
the signer partitions {.9i, • • • , into smaller sets and pre- 
compulcs each of them. If each smaller set contains four si, 
then it is a 4-bit precomputation. Similarly, if each .smaller 
set contains eight Si, then it is an 8-bil precomputation. For 
4-bit precomputation with k = 128 and 512-bit modulus, 
a signer needs to store 128/4 x (2'^ - 1) = 480 products. 
That is, additional memory of 480 x 512 bits or 31 kB is 
required. The additional memory required by 8-bit, l2-bil, and 
16-bil precomputation arc 261 kl), 2.88 MB, and 33.6 MB, 
respectively. 

''in pracnce. for k up to 128, the vcnlkation key components {i^} arc 
Ic.'js than 2'". and each coiuponcnt can be stored in 1 6 biis. 
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eFFS Signing Time (Milliseconds) With 512-Bit Modulus 







eFFS parameter (fc.t) 






(32,1) 


(32.2) 


(64,1) 


(32,4) (64.2) 


(128,1) 


basic FFS 


3.96 


7.87 


7.21 


15.62 14.35 


13.72 


small v-kcy 


3.95 


7.84 


7.21 


15.63 14.36 


13.72 


crt 1 small v-kcy 


3.13 


6.20 


5.35 


12.44 10,63 


9.78 


precomp + crt + small v-key 


1.95 


3.84 


2.99 


7.61 5.92 


5.08 


8-bit precomp + crt -1- small v-key 


1.47 


2.87 


2.02 


5.67 3-98 


3.14 



TABLE IV 

eFFS Verification Time (Milliseconds) With 512-Bit Modulus 







cFFS parameter (A: 


.<) 






(32,1) 


(32,2) 


(64.1) 


(32,4) 


(64.2) 


(128.1) 


basic FFS 


3.65 


7.07 


7.12 


14.01 


13.63 


13.44 


small v-key 


0.33 


0.62 


0.43 


1.21 


0.81 


0.65 


4-bit precomp + small v-key 


0.32 


0.60 


0,41 


1.16 


0,76 


0.59 


8-bit precomp + small v-key 


0.32 


0.59 


0.40 


1.14 


0.74 


0.57 



Although a similar precomputation can be used in verifica- 
tion, it is not eflective with the small v-key extension. This is 
because when small primes are used as public key components, 
their products can be computed very efficiently. 

4) Performance Comparison We implemented the three 
speedup extensions using the large integer arithmetic routines 
from CryptoLib [8). Tables III and IV show the times for 
signing and verifying (with 512-bit modulus) 128-bit message 
digests using different speedup extensions for differenl values 
of (A;,().'^ The results were obtained on a Pentium II 300 MHz 
machine running Linux. Note that, for a fixed kt product, the 
signing/verification time is smaller when t is smaller. 

In the experiments to be reported in the balance of this 
paper, we used S-hii precomp + crt -f small v-key for eFFS 
signing, and small v-key only for eFFS verification. 

C Adjustable and Incremental Verification 

In multicast or group communications, receivers typically 
have diflerent amounts of resources, and the resources avail- 
able to a receiver for verification vary over time. It is thus 
desirable to have an adjustable and incremental signature 
verification operation. With this extension, a signature can be 
verified at different security levels. An adjustable verification 
allows a receiver to verify a message at a lower security 
level using less resources. An incremental verification allows 
a receiver to verify a message at a lower security level first, 
and later increase the security level by using more resources 
(e.g., if the message is important). 

Since the security level of a signature scheme depends on 
its parameters, e.g., the modulus size, an obvious approach to 
provide adjustable and incremental verification is to use mul- 
tiple keys (with differeiM modulus sizes) to generate multiple 
signatures for different security levels. To verify at a lower 
security level, the verification key with a shorter modulus size 
is used to verify the corresponding signature. This approach 
is simple but very inefficient. In the following, we design 

'M'or basic FFS, we specified signing key components {si). Verification 
key components { v, \ were chosen by CryptoLib. 



TABLE V 

eFFS f-LEVEL Signature Signing Times (Millisiiconds) 





kt product 






kt = 32 kt=- ()4 ki 


= 128 


1-tcvcl bigndture 


1.47 2.02 


3.14 


2'levcl signature 


2.87 


3.98 


4-level signature 




5.67 



an extension to FFS that provides adjustable and incremental 
verification efficiently. 

Our extension to provide adjustable and incremental veri- 
fication is to use t greater than one, and to include {x*} for 
t = 2, • • • ,i in signatures. This is called a t-level signature}^ 
This extension is as secure as the original scheme because Xi = 
Vi ^ (^1*^ X • ■ X v^^^ ) mod n for i = 2, • • • , i can be computed 
easily from the original signature, which consists of {bij} and 
{Vt}, together with the verification key {ui, • • , Vfc,n} which 
is publicly known. 

To verify a f-level signature of message m at security level 
/ of t (where / < t), a verifier docs the following: (1) compute 
Zi == J/? X (vj" X • • X vl'^ ) mod ti for i = 1, • • • , / and (2) 
verify that 2:2. * ' , '^r are equal io xzr ■ '^ respectively, and 
the first k X t bits of h{m,zi,X2, ■ ■ .^t) are equal to the 
[bij] received. 

To increase the verification security level fi-om li to a 
verifier does the following: 1) compute Zi = yf x (vj'* x 
• ■ X i;^;')modn for i = /i + 1, ■•,/2, and 2) verify that 
«/i +1 , • • • , ^/v are equal to :r/, ^ 1 , • • ■ , xi.^ , respectively. 

The size of a Mevel signature is kt'^{2t -l)x \n\ bits. For 
512-bit modulus and product kt = 128, a I -level signature is 
80 bytes and a 2-lcvel signature is 208 bytes. 

Table V shows different Mevel signature signing times. 
For the same kt product, the signing time increases as the t 
value increases. However, the signing time is still smaller than 
using multiple keys to implement different security levels. For 
example, the 2-level signature signing lime, which is 3.98 ms 
for kt = 128, is smaller than the lime to sign two (original 

•^Noic that ihc original (I -level) signature di>cs not provide adjustable and 
incremental vcriflcation. 
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TABLE VI 

eFFS INCREMI-NTAL VERIFICATION TlMES (MlLLISBCONDS) FOR kt = 128. 

(a) 2-LcvEL SiCNATURC. (b) 4-LiivtL Signature. 



To 


level 1 


level 2 


From level 0 


0.42 


0.81 


Prom level 1 




0.40 



(a) 



To 


level 1 


level 2 


level 3 


level 4 


FVom level 0 


0.34 


0.G3 


093 


1.22 


Prom level 1 




0.30 


0.60 


0.89 


Prom level 2 






0.30 


0.60 


Prom level 3 








031 



(b) 



i -level) signatures, one for {k,t) = (64, 1) and the other for 
{k,t) = (128, 1), which is 2.02 -h 3.14 = 5.16 ms. 

Tabic VI shows the (incremental) verification times from 
one level to a higher level for a 2-level signature and a 4-level 
signature with kt = 128. In particular, for a 2-level signature, 
a verifier can first verify a message at level 1 of 2 using 0,42 
ms processor time, and later increase to level 2 (of 2) by using 
0.40 ms additional processor time. 

IV. Comparison With Other Signaturh Schemes 

In this section, we compare eFFS(128, 1) to FFS(128, 1) as 
well as four other signature schemes available from CryptoLib 
[8], namely: DSA [15], ElGamal [8], RSA [19], and Rabin 
[17], We compare their key and signature sizes, and signing 
and verification times. Then, we compare their signing and 
verification rates for 1024-byte packets when each is used 
as the signature scheme in our flow signing and verification 
procedures presented in Section II. Experiments were per- 
formed on a Pentium II 300-MHz machine running Linux. 
Four different modulus sizes, 384, 512, 768, and 1024 bits, 
were used in the comparison. (Note that it is difficult to 
compare the security levels of dilTerent signature schemes even 
if Ihcy use the same modulus size.) 

A. Key and Signature Sizes 

Table VII shows the signing/verification key and signature 
sizes. The signing keys are from 96 to 384 bytes in all schemes 
except Fl'S and eFFS whose signing keys are much larger, 
from 6192 lo 16 512 bytes. Note that a signing key is private 
to a signer. We do not expect the relatively large eFFS signing 
keys to pose a problem for sources/signers of packets.'^ 

In RSA and Rabin, verification keys are fi-om 48 to 128 
bytes. In DSA, ElGamal, and cFFS, verification keys are 
slightly larger, from 144 to 404 bytes. Even for receivers with 
limited resources, we believe that a verification key as large 
as 400 bytes would not pose a problem. (Noie that witlioul 
the small v-kcy extension, VVS verification keys are as large 
as signing keys.) 

'^Siich sij^iniig keys iire. indeed, loo largo for small devices, such as 
sniartcards, hut ii is unlikely ihat these devices would be sources of packet 
flows or muliicasis. 
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TABLE VII 

Signing Kav, Verification Key, and Signaturh Sizus (Byths) of Differfnt 
Signature Schemes, (a) Signing Key Sizes (Bytes), (b) Verification 
Key Sizes (Bytes), (c) Signature Sizes (Bytes). 



modulus size (bits) 
384 512 7C8 1024 



RSA 


96 


128 


192 


256 


Rabin 


9G 


128 


192 


250 


DSA 


136 


168 


232 


296 


ElGamal 


144 


192 


288 


384 


FFS(128,1) 


6192 


8256 • 


12384 


16512 


eFFS(128.1) 


6192 


8256 


12384 


16512 


(a) 


RSA 


48 


64 


96 


128 


Rabiu 


48 


64 


90 


128 


DSA 


164 


212 


308 


404 


ElGamal 


144 


192 


288 


384 


FFS(128,1) 


6192 


8256 


12384 


16512 


eFFS(128,l) 


304 


320 


352 


384 


(b) 


RSA 


48 


64 


96 


128 . 


Rabin 


48 


04 


90 


128 


DSA 


40 


40 


40 


40 


ElGamal 


96 


128 


192 


256 


FFS(128,1) 


64 


80 


112 


144 


eFFS(128,l) 


G4 


80 


112 


144 



(c) 



The signature of DSA is Ihe smallest and is 40 bytes for all 
modulus sizes. For all of the other schemes, the signatures are 
larger and about the same size, 48 to 256 bytes. In particular, 
the signature sizes of eFFS and the popular RSA are about 
the same. 

B. Signing and Verification Times 

Table VIII shows the signing and verification times for 
a 16-byte message (digest). DSA and ElGamal have been 
designed to achieve efficient signing (e.g., for use in smartcard 
applications), and RSA and Rabin have been designed to 
achieve efficient verification. From Table VIII, note that the 
signing operations of DSA and ElGamal, with times from 3.9 
to 18.9 ms. are much more efficient than those of RSA and 
Rabin, with times from 6,2 to 95.9 ms. On the other hand, 
the verification operations of RSA and Rabin, with times Irom 
0.14 to 1.14 ms, are much more efficient than those of DSA 
and ElGamal, with times from 5.1 lo 350.3 ms. 

Note that the signing and verification operations of FFS 
are both inefficient. However, cFFS has a signing operation 
even more efficient than those of DSA and ElGamal. and 
a verification operation as efficient as that of RSA. This 
combination of the most efficient signing and highly efficient 
verification makes cFFS the best choice for most applications. 

C Flow Signing and Verification Rates 

Table IX shows the flow signing and verification rates of our 
flow signing and verification procedures (for 1024-byte pack- 
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TABLE Vm 

SroNfNG AND VERiFYJNCi Times (Millisi-conds) of Dii-wrent 
Signature Schemes, (a) Signing Time (Milliseconds). 
(b) Verification Time (Milliseconds). 

modiiliifl size (bits) 
384 512 768 1024 



RSA 
Rabin 
DSA 
ElGamal 
FFS(128,l) 
eFFS(128,l) 



6.2 
11.3 
3.9 
5.1 
8.8 
2-3 



12.7 
19.5 
5.6 
6.8 
13.7 
3.1 



36.2 
47.5 
10.2 
12.3 
22.9 
6.2 



79.4 
96.9 
16.3 
18.9 
38.5 
8.2 



(a) 



modulus size (bits) 





384 


612 


768 


1024 


RSA 


0.26 


0.40 


0.70 


l.l 


Rabin 


0.14 


0.20 


0.38 


0.66 


DSA 


5.1 


7.6 


14.7 


24.2 


ElGamal 


24.4 


51.9 


157.5 


350.3 


FFS(128,1) 


8.5 


13.4 


22. J 


37.3 


eFFS{r28,l) 


0.53 


0.65 


0.82 


1,1 



(b) 

TABLR IX 

Flow Signincj and Verii-ication Rates (Packets/S) for 1024-Byte Packets, 

DF.GREE Two TREE CHAINING, AND BLCX:K SI/J: SIXTEEN, (a) FLOW SIGNING 

Rate (Packeis/s). (b) Fi.ow Vi;rii-ication Rate (Packuts/s). 

modulus size (bits) 



RSA 
Rabin 
DSA 
ElGamal 
FFS(128.1) 
cFFS( 128.1) 



384 612 708 1024 



1940 
1200 
2760 
2320 
1550 
3920 



1090 
739 
2140 
1850 
1070 
3140 



413 
321 
1320 
1140 
624 
2160 



193 
163 

874 
740 
395 
1610 



(a) 



Ri5A 
Rabin 
DSA 
ElGamal 
FFS(128,1) 
eFFS(128^1| 



modulus size (bits) 
384 512 768 1024 



7480 7030 6060 5290 

7900 7610 7010 0430 

2270 1660 949 609 

600 295 99 45 

1590 1150 633 419 

0640 G370 5760 5250 



(b) 

els, degree-two tree chaining, block size sixteen, and !00% 
of processor lime of a Penlium II 300-MHz machine). Both 
DSA and ElGamal have low flow verification rates, rendering 
ihem inappropriate for receivers with limited resources, such 
as personal digital assistants and low-end notebook computers. 
Both RSA and Rabin have low flow signing rates, rendering 
them inappropriate for real-time generated flows, such as live 
video/audio applications. By comparison, eFFS provides high 
flow signing rates suitable for real-time generated flows while 
its flow verification rates are also very high. 

V. Conclusion 

We investigated ihe problem of signing/verifying delay- 
sensitive packet flows to provide data authenticity, integrity, 



and nonrepudiation for Internet applications. We have designed 
flow signing and verification procedures, based upon a tree- 
chaining technique, to meet the following requirements: 1) 
flow signing is efficient and, for real-time generated flows, 
delay-bounded; 2) flow verification is efficient (for receivers 
with limited resources); 3) packets in a flow are individually 
verifiable (for best-effort multicast delivery); 4) packet sig- 
natures are small (for a small communication overhead); and 
5) verification at a receiver is adjustable to different security 
levels and can be carried out incrementally (for receivers with 
limited resources). 

We implemented our flow signing and verification proce- 
dures and performed experiments to compare different chain- 
ing techniques. From experimental results, we recontmend the 
use of degree-two (binary) tree chaining since it requires the 
smallest packet signature size (i.e., smallest communication 
overhead) while its signing and verification rates are compara- 
ble to the rates of other chaining techniques. Our flow signing 
and verification procedures are very efficient and achieve one 
to two orders of magnitude improvement compared to the 
sign-each approach. 

Since signed packets in our procedures are individually 
verifiable, the procedures can be used to reduce the workload 
of any machine that sends out a large number of signed packets 
to one or more destinations. There is no requirement that these 
packets belong to flows. However, for packets that belong to 
a flow, the workload of the flow's receiver(s) is also reduced. 

To further improve our procedures, we propose several ex- 
tensions to the Feige-Fiat-Shamir digital signature scheme [3], 
[4] to speed up both the signing and verification operations, 
as well as to allow adjustable and incremental verification. 
The extended scheme, called eFFS, is compared to four other 
digital signature schemes, RSA [19], Rabin [17], DSA [15], 
and ElGamal [6], on the same computing platfomn (Pentium 
II 300-MHz machine running Linux). 

The signing operation of eFFS is by far the most efficient 
of all the schemes compared. The verification operation of 
eFFS is as efficient as that of RSA (tie for a close second 
behind the verification operation of Rabin). In addition to 
efficient signing and verification, we have extended the eFFS 
scheme to allow a receiver to efficiently carry out adjustable 
and incremental verification. Such a capability is useful for 
large-scale multicast applications with a variety of receivers 
including some with limited resources. 

Apphnoix 
Flow VtRii-tcAnoN Pkockdui^i- 

procedure flowvcrify() 
for each received packet 

if the block signature sign(root) in the packet signature 
is new then 

/* this is the first received packet in the block *l 

compute the packet digest; 

compute each ancestor of the packet digest 

as the message digest of its children; 
let root' be the computed block digest; 
if (vcrify(rfW. sign{yoo{)) - false) then 

the packet is not verified 
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else 

the packet is verified; 

cache all computed nodes and their children 
as verified 

end if 

else /* this is not the first received packet in the block */ 
compute the packet digest; 
if (packet digest has been cached) then 

if (computed packet digest ^ its cached value) 

then the packet is not verified 
else 

the packet is verified 
endif 

else 

compute all noncached ancestors of the 

packet digest; 
lei node be the highest node computed; 
compute the parent of node; 
if (computed parent ^ its cached value) then 

the packet is not verified 
else 

the packet is verified; 

cache all computed nodes and their children 
as verified 
endif 
endif 
endif 
end for 
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